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Advertising Node Administrative Tags in IS-IS 
Abstract 


This document describes an extension to the IS-IS routing protocol to 
advertise node administrative tags. This optional capability allows 
tagging and grouping of the nodes in an IS-IS domain. The node 
administrative tags can be used to express and apply locally defined 
network policies, thereby providing a very useful operational 
capability. Node administrative tags may be used by either IS-IS 
itself or other applications consuming information propagated via IS- 
Is. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7917. 
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Introduction 


It is useful to assign a node administrative tag to a router in the 
IS-IS domain and use it as an attribute associated with the node. 
The node administrative tag can be used in variety of applications. 
For example: 


(a) Traffic-engineering applications to provide different 
path-selection criteria. 


(b) Preference for, or pruning of, certain paths in Loop-Free 
Alternate (LFA) [RFC5286] backup selection via local policies as 
defined in [RFC7916]. 


This document provides mechanisms to advertise node administrative 
tags in IS-IS for various applications, including (but not limited 
to) route and path selection. Route and path selection functionality 
applies to both Traffic Engineering (TE) and non-TE applications. 
Hence, the new sub-TLV for carrying node administrative tags is 
included in the Router CAPABILITY TLV [RFC4971]. 


1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Node Administrative Tags 


An administrative tag is a 32-bit unsigned integer value that can be 
used to identify a group of nodes in the IS-IS domain. An IS-IS 
router should advertise in the specific IS-IS level the set of groups 
of which it is a part. 


As an example, all edge network devices in a given network may be 
configured with a certain tag value, whereas all core network devices 
may be configured with another, different tag value. 


Node Administrative Tag (Node-Admin-Tag) Sub-TLV 


The new sub-TLV defined in this document is carried within an IS-IS 
Router CAPABILITY TLV (IS-IS TLV type 242) [RFC4971] in the Link 
State PDUs originated by the device. Router CAPABILITY TLVs 
[RFC4971] can have "level-wide" or "domain-wide" flooding scope. The 
choice of flooding scope in which a specific node administrative tag 
shall be flooded is purely a matter of local policy and is defined by 
the operator’s usage needs. An operator MAY choose to advertise a 
set of node administrative tags across levels and another different 
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set of node administrative tags within the specific level. 
Alternatively, the operator may use the same node administrative tags 
within both the "domain-wide" flooding scope and one or more 
"level-wide" flooding scopes. 


The format of the Node Administrative Tag (Node-Admin-Tag) sub-TLV 
(see Section 3.1) does not include a topology identifier. Therefore, 
it is not possible to indicate a topology-specific context when 
advertising node administrative tags. Hence, in deployments using 
multi-topology routing [RFC5120], advertising a separate set of node 
administrative tags for each topology SHOULD NOT be supported. 


3.1. TLV Format 


[RFC4971] defines the Router CAPABILITY TLV, which may be used to 
advertise properties of the originating router. The payload of 
the Router CAPABILITY TLV consists of one or more nested 
Type-Length-Value (TLV) triplets. 


The new Node-Admin-Tag sub-TLV, like other IS-IS sub-TLVs, is 
formatted as TLV triplets. Figure 1 below shows the format of the 
new sub-TLV. 


0 1 2 3 
0.:1:2-34-306.7:89:0-1.:2 34 5-6.:78:9 0 1.02:3:4. 056408: 9 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | 
4-4-4-4-4-4-4-4-4-4-4+-4+-4+-4-4+-4-4+-4+-4+-4+-4-4-4-4+-4-4-4-4+-4-4-4-4-4 
| Administrative Tag #1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| Administrative Tag #2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
// // 
E +++ 
| Administrative Tag #N | 
4-4-4-4-4-4-4-4-4-4+-4+-4-4-4-4+-4+-4+-4+-4+-4-4-4+-4+-4-4-4-4-4-4-4-4-4-4 


Type: 21 (Node-Admin-Tag) 
Length: An 8-bit field that indicates the length of the Value 
portion in octets; this will be a multiple of 4 octets, 


depending on the number of tags advertised. 


Value: Defines the node administrative tags (Administrative Tag #1, 
Administrative Tag #2, etc.). Multiples of 4 octets. 


Figure 1: IS-IS Node-Admin-Tag Sub-TLV 
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4. Elements of Procedure 
4.1. Interpretation of Node Administrative Tags 


The meaning of node administrative tags is generally opaque to IS-IS. 
A router advertising one or more node administrative tags may be 
configured to do so without knowing (or even explicitly supporting) 
the functionality implied by the tag. This section describes general 
rules, regulations, and guidelines for using and interpreting a node 
administrative tag; these rules, regulations, and guidelines will 
facilitate interoperable implementations between vendors. 


Interpretation of tag values is specific to the administrative domain 
of a particular network operator. Hence, tag values SHOULD NOT be 
propagated outside the administrative domain to which they apply. 

The meaning of a node administrative tag is defined by the network 
local policy and is controlled via configuration. If a receiving 
node does not understand the tag value, it ignores the specific tag 
and floods the Router CAPABILITY TLV without any change, as defined 
in [RFC4971]. 


The semantics of the tag order has no meaning. There is no implied 
meaning to the ordering of the tags that indicates a certain 
operation or set of operations that need to be performed based on the 
ordering. 


Each tag SHOULD be treated as an independent identifier that may be 
used in a policy to perform a policy action. Each tag carried by the 
Node-Admin-Tag sub-TLVs should be used to indicate a characteristic 
of a node that is independent of the characteristics indicated by 
other administrative tags within the same instance or another 
instance of a Node-Admin-Tag sub-TLV. The list of node 
administrative tags carried in a Node-Admin-Tag sub-TLV MUST be 
considered as an unordered list. Whilst policies may be implemented 
based on the presence of multiple tags (e.g., if tag A AND tag B are 
present), they MUST NOT be reliant upon the order of the tags (i.e., 
all policies should be considered commutative operations, such that 
tag A preceding or following tag B does not change their outcome). 


4.2. Use of Node Administrative Tags 


The node administrative tags are not meant to be extended by future 
IS-IS standards. New IS-IS extensions are not expected to require 
the use of node administrative tags or define well-known tag values. 
Node administrative tags are for generic use and do not require IANA 
registration. Future IS-IS extensions requiring well-known values 
MAY define their own data signaling tailored to the needs of the 
feature or MAY use the Router CAPABILITY TLV as defined in [RFC4971]. 
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Node administrative tags are expected to be associated with a stable 
attribute. In particular, node administrative tags MUST NOT be 
associated with something whose state can oscillate frequently, e.g., 
the reachability of a specific destination. 


While no specific limit on the number of node administrative tags 
that may be advertised has been defined, it is expected that only a 
modest number of tags will be required in any deployment. 


4.3. Processing Node Administrative Tag Changes 


Multiple Node-Admin-Tag sub-TLVs MAY appear in a Router CAPABILITY 
TLV, or Node-Admin-Tag sub-TLVs MAY be contained in different 
instances of Router CAPABILITY TLVs. The node administrative tags 
associated with a node that originates tags for the purpose of any 
computation or processing at a receiving node SHOULD be a superset of 
node administrative tags from all the TLVs in all the instances of 
Router CAPABILITY TLVs received in the Link State PDU(s) advertised 
by the corresponding IS-IS router. When a Router CAPABILITY TLV is 
received that changes the set of node administrative tags applicable 
to any originating node, a receiving node MUST repeat any computation 
or processing that makes use of node administrative tags. 


When there is a change to, or removal of, an administrative 
affiliation of a node, the node MUST re-originate the Router 
CAPABILITY TLV(s) with the latest set of node administrative tags. 

On a receiving router, on detecting a change in contents (or removal) 
of existing Node-Admin-Tag sub-TLV(s) or the addition of new 
Node-Admin-Tag sub-TLV(s) in any instance of Router CAPABILITY 
TLV(s), implementations MUST take appropriate measures to update 
their state according to the changed set of node administrative tags. 
The exact actions needed will vary, depending on what features are 
associated with node administrative tags; this topic is outside the 
scope of this specification. 
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Applications 


[RFC7777] lists several non-normative examples of how implementations 
might use node administrative tags. These examples are given only to 
demonstrate the generic usefulness of the router tagging mechanism. 
An implementation supporting this specification is not required to 
implement any of the use cases. The following is a brief list of 
non-normative use cases listed in [RFC7777]. Please refer to 

Section 3 of [RFC7777] for more details. 


1. Auto-discovery of services 
2. Policy-based Fast Reroute (FRR) 
(a) Administrative limitation of LFA scope 
(b) Optimizing LFA calculations 
3. Controlling remote LFA tunnel termination 
4. Mobile backhaul network service deployment 
5. Policy-based explicit routing 
Security Considerations 


This document does not introduce any new security issues. Node 
administrative tags, like link administrative tags (a.k.a. 
administrative groups) [RFC5305], can be used by operators to 
indicate geographical location or other sensitive information. The 
information carried in node administrative tags, like link 
administrative tags, can be leaked to an IGP snooper. 


Advertisement of tag values for one administrative domain into 
another involves the risk of misinterpretation of the tag values (if 
the two domains have assigned different meanings to the same values) 
and may have undesirable and unanticipated side effects. 


Security concerns for IS-IS are already addressed in [1S010589], 
[RFC5304], and [RFC5310] and are applicable to the mechanisms 
described in this document. Extended authentication mechanisms 
described in [RFC5304] or [RFC5310] SHOULD be used in deployments 
where attackers have access to the physical networks, because nodes 
included in the IS-IS domain are vulnerable. 
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Operational Considerations 


Operators can assign a meaning to the node administrative tags that 
is local to the operator’s administrative domain. The operational 
use of node administrative tags is analogical to the IS-IS prefix 
tags [RFC5130] and BGP communities [RFC1997]. Operational discipline 
and procedures followed in configuring and using BGP communities and 
IS-IS prefix tags are also applicable to the usage of node 
administrative tags. 


Defining a language for local policies is outside the scope of this 
document. As is the case with other policy applications, the pruning 
policies can cause the path to be completely removed from the 
forwarding plane and hence have the potential for a more severe 
impact on operations (e.g., node unreachability due to path removal) 
as compared to preference policies that only affect path selection. 


Manageability Considerations 


Node administrative tags are configured and managed using routing 
policy enhancements. YANG [RFC6020] is a data modeling language used 
to specify configuration data models. The IS-IS YANG data model is 
described in [YANG-ISIS-CFG], and the routing policy configuration 
model is described in [RTG-POLICY-MODEL]. At the time of writing 
this document, some work to enhance these two other documents so that 
they include configurations related to node administrative tags is 
either already in progress or shall be taken up soon. 


IANA Considerations 


This specification updates one IS-IS registry: the "Sub-TLVs for 
TLV 242" registry. The following value has been registered. 


Value Description 


21 Node-Admin-Tag 
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